home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 13905 < prev    next >
Encoding:
Text File  |  1996-08-05  |  3.2 KB  |  83 lines
  1. Newsgroups: comp.object,comp.lang.eiffel,comp.lang.c++,comp.lang.beta,comp.lang.java,comp.lang.sather
  2. Path: newsfeed.acns.nwu.edu!ftpbox!mothost!schbbs!news
  3. From: shang@corp.mot.com (David L. Shang)
  4. Subject: Re: What Should An Exception Handling Do? -- Clarification of rules
  5. Reply-To: shang@corp.mot.com
  6. Organization: MOTOROLA 
  7. Date: Wed, 27 Mar 1996 21:11:17 GMT
  8. Message-ID: <1996Mar27.211117.5569@schbbs.mot.com>
  9. References: <4j954n$mrq@kai.com>
  10. Sender: news@schbbs.mot.com (SCHBBS News Account)
  11. Nntp-Posting-Host: 129.188.128.126
  12.  
  13. In article <4j954n$mrq@kai.com> robison@kai.com (Arch Robison) writes:
  14. > I think that you missed the point of Bjarne Stroustrup's post.
  15. > It is easy to think of examples supporting any language feature.
  16. > The point is that people actually programming with real languages
  17. > on real projects found that resumption semantics were inferior
  18. > to termination semantics.
  19. >
  20.  
  21. Note that resumption is not simply going back to the place where the
  22. exception is raised, rather, it is a retry from the original starting
  23. point. I don't see any inferior with this resumption semantics, which
  24. is broardly accepted in alomost all OO languages that offer exception
  25. handling.
  26.  
  27. > Stroustrup was kind enough not to post his whole Design and Evolution (D&E)
  28. > book.  Go read it.  Section 16.6 says more than the post.  Section 16.6.1 
  29. > explains how to get most of the benefits of resumption semantics with C++.
  30.                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  31. > 
  32.  
  33. If resumption semantics were inferior, why should we bother to get
  34. its "benefits" by simulating its semantics as below:
  35.  
  36. > This is an unfair comparison, since the latter example code uses C++ features
  37. > badly.  It's wordiness is more an artifact of the switch syntax than
  38. > exception semantics.  I offer the following pseudocode as an improved 
  39. > version.  It presumes that unusual conditions throw an exception, so it
  40. > does not make calls to the hypothetical "check_error_message".
  41. > 
  42. >     bool retry;
  43. >     do {
  44. >     retry = false;
  45. >     try {
  46. >         result = do_something();
  47. >     }
  48. >     catch( condition1 ) {some_extraordinary_work1();  retry=true;}
  49. >     catch( condition2 ) {some_extraordinary_work2();  retry=true;}
  50. >     catch( condition3 ) {some_extraordinary_work3();  retry=true;}
  51. >         catch( condition4 ) {result=NULL;}
  52. >     } while( retry );
  53. > 
  54.  
  55. How do you define these conditions? They must be in different types,
  56. I assume, otherwise C++ cannot locate the cather.
  57.  
  58. What happen if we forget to inialize "retry"? Okay, we can use break, but
  59. what happen if we have nested exceptions? "Goto" must be used, I guess.
  60. Busy jumps around are no fun.
  61.  
  62. What happen if we forget to set "result" to NULL under condition4?
  63. In code:
  64.  
  65. result    = try do_something()
  66.       {
  67.         when condition1: some_extraordinary_work1; retry;
  68.         when condition2: some_extraordinary_work2; retry;
  69.         when condition3: some_extraordinary_work3; retry;
  70.         when condition4: return null;
  71.       }
  72.  
  73. "return" is a must.
  74.  
  75. What happen if the exception is thrown and the caller does not provide any
  76. catcher? Either crash the system or leave the invlid result alone?
  77.  
  78. In Transframe, "try" is a must, if "do_something" declares exceptions that
  79. must have caller's involvement.  
  80.  
  81. David Shang
  82.  
  83.